Re: SUMMARY Security Info (root broken)
Luke Mewburn (lm@melb.cpr.itg.telecom.com.au)
Tue, 4 Oct 1994 08:36:21 +1000 (EST)
> Preventative measures include ensuring that all accounts have a mailbox,
> even an empty one. Set the global /usr/lib/Mailrc file to include
> the line 'set keep', and build all other mail user agents to leave
> an empty mailbox, instead of deleting it when one deletes all mail.
> When adding a user, create a zero-length mailbox for that user.
> [ ... ]
> And most important, REPLACE OR FIX BINMAIL. The current patch offered
> by Sun apparantly does NOT fix the problem, only alters it. Using
> something built from mail.local.c from the NetBSD distribution is a good
> alternative.
> [ ... ]
> One of the respondents (Chuck Cranor - chuck@maria.wustl.edu) sent such
> a replacement he has used, it is included in this summary. BE WARY OF
> ALL PRIVILEGED PROGRAMS THAT CREATE TEMPORARY FILES IN /tmp. Too often
> these programs also have a race condition, and one can predict the name
> of the temp file the program will use, and thus exploit this. This is
> not helped by having all the mailboxes in place, since this works in
> tmp instead of the mail spool. If one has source, at lease make sure
> that the temp files are created and opened via the mkstemp() call, not
> mktemp() followed by an open. Check via lstat and fstat to ensure the
> file one opens is the one that one THINKS one is opening. The program
> appended adds another wrinkle - using chroot() and fchroot() to limit
> the scope of where links can point to if a link is somehow slipped under
> the the program via winning a race. As long as checking the file to be
> opened and the open are not atomic, potential for this problem exists
> with privileged programs.
I think that Pat has highlighted here the problem with a lot of
packages that use a setuid root process to create a file in a
restricted directory (e.g, a 775 root.mail /var/spool/mail.)
I've looked at the 4.4BSD-lite (NetBSD uses this) mail.local.c and at
first, thought there was a potential race condition in the code
where it does an lstat check then an open, thinking there was a race
condition. Checking the man page for open() however, revealed the
following tidbits:
If path is a symbolic link and O_CREAT and O_EXCL are set,
the link is not followed.
(From Solaris 2.3, and the NetBSD-current man page says something
similar.)
So, it seems that a standard (POSIX?) has explicitly given us a method
to atomically create a file if it doesn't exist, whilst at the same
time not getting fooled by a dangling symlink (which is a common way
to exploit setuid race conditions, correct?)
Now, I don't know if this helps people on systems where this behaviour
doesn't exist (I'm not sure if Sunos 4 supports this, for example.)
It's the creating of the new file by a priviliged process that
is the critical region that so often gets spoofed by a race
condition. I have some (simple - thus easy to follow and assure
is correct - I hope :) code at home that I was working on which should
work without a race condition (using the atomic link()), so I'll
post it tomorrow to get disected by those with more experience than
I. If it does work the way I expect it to, I feel that a simpler,
more effective, mail.local could be implemented that didn't rely upon
the O_CREAT | O_EXCL feature of newer systems I described above...
Luke.
[ Sorry if this has been discussed already; I've only recently joined
bugtraq.]
--
Luke Mewburn, <lm@cpr.itg.telecom.com.au>
`Think of it as Evolution in Action.' - "Oath of Fealty", Niven & Pournelle